Empirische Bewertung von Perfomanz-Vorhersageverfahren für Software-Architekturen

Die Architektur eines Software-Systems beeinflusst maßgeblich seine Qualitätseigenschaften wie Performanz oder Zuverlässigkeit. Daher sind Architekturänderungen oft die einzige Möglichkeit, Mängel bei diesen Qualitätseigenschaften zu beheben. Je später diese Änderungen an der Architektur während des Software-Entwicklungsprozesses vorgenommen werden, desto teurer und riskanter sind sie. Aus diesem Grund ist eine frühzeitige Analyse verschiedener Architektur-Entwurfsalternativen bezüglich ihrer Auswirkungen auf Qualitätseigenschaften vorteilhaft. Dieser Artikel beschreibt die Evaluation dreier verschiedener Performanz-Vorhersageverfahren für Software-Architekturen hinsichtlich ihrer Eignung, korrekte Empfehlungen für frühzeitige Entwurfsentscheidungen zu geben. Zusätzlich sollen diese Vorhersageverfahren prüfen, ob extern vorgegebene Performanz-Anforderungen realisierbar sind. Die Performanz-Vorhersageverfahren ” SPE“, ” Capacity Planning“ und ” umlPSI“ wurden empirisch durch 31 Teilnehmer untersucht, die eine Menge vorgegebener Alternativen beim Entwurf der Architektur eines Webservers zu bewerten hatten. Die Ergebnisse zeigen, dass Entwurfsalternativen mit allen Verfahren richtig bewertet wurden, sofern deutliche Auswirkungen auf die Performanz vorhanden waren. Ohne den Einsatz der Performanz-Vorhersageverfahren wurden häufiger weniger performante Entwurfsalternativen vorgeschlagen. Darüber hinaus konnte das Verfahren Capacity Planning die absoluten Werte bei den meisten Entwurfsalternativen relativ genau vorhersagen. 1 Einleitung und Motivation Eine der Motivationen zur Beschreibung von Software-Architekturen ist die explizite Behandlung von Qualitätseigenschaften [SG96]. Dies ist begründet in dem Einfluss, den die Architektur eines Software-Systems auf seine Qualitätseigenschaften hat. Heute gängige Software-Entwicklungsverfahren sind getrieben durch die Umsetzung funktionaler Anforderungen in Entwürfe und Implementierungen, wohingegen die Einhaltung nichtfunktionaler Eigenschaften erst in späteren Phasen des Entwicklungsprozesses beachtet wird. Werden in diesen späten Phasen gravierende Qualitätsprobleme (oft im Zusammenhang mit Skalierbarkeit) festgestellt, reichen meist vereinzelte lokale Code-Optimierungen nicht aus. Stattdessen muss dann die Architektur grundlegend überarbeitet werden, um ursprüngliche Qualitätsvorgaben realisieren zu können. Angesichts der Kosten, Risiken und des Zeitbedarfs der späten Architekturänderungen, wird die Problematik eines solchen Vorgehens schnell offenbar. Aufgrund dieser Herausforderungen beim Architekturentwurf ist das Gebiet der Architekturanalyse ein Feld aktiver Forschung (ein aktueller Überblick findet sich in [BDIS04]). Unter der Qualitätseigenschaft ” Performanz“ verstehen wir alle zeitlichen Maße der Effizienz, insbesondere die Maße ” Antwortzeit“, ” Reaktionszeit“ und ” Durchsatz“. Aufgrund der Wichtigkeit der Performanz für eine Vielzahl von Systemen betrachten wir im folgenden Architektur-Analyse-Verfahren für Performanz. Wir beschäftigen uns mit der Frage, ob Performanz-Vorhersageverfahren die im Vergleich zur gemessenen Performanz der Implementierung richtige Entwurfsalternativen empfehlen. Bisher wurde diese Fragestellung noch nicht empirisch untersucht. Ein erster Ansatz ist die Feldstudie [BMDI04], die ein auf stochastischen Prozessalgebren basierendes Verfahren mit einem Simulationsverfahren vergleicht. Allerdings wurden die Vorhersagen nicht mit gemessenen Werten verglichen. Auch ist der Einfluss der durchführenden Person auf die Qualität der Vorhersage unklar, da nicht mehrere Personen ein Verfahren anwendeten. Gorton et. al. [GL03] vergleichen Vorhersagen und Messungen von verschiedenen Software-Architekturen auf Basis von Enterprise JavaBeans. Dabei werden aber keine verschiedenen Vorhersageverfahren verglichen. Die Methodik des experimentellen Software Engineering wird erläutert in [Pre01, JM01, WRH00]. Für unsere Studie wurden die Vorhersageverfahren ” Software Performance Engineering (SPE)“ [Smi02], ” Capacity Planning (CP)“ [MAD04] und ” umlPSI“ [Mar04] ausgewählt, zum einen da sie als prototypische Vertreter ihrer Klasse von Vorhersageverfahren angesehen werden können, also analytisch-schätzungenbasiert bei SPE, analytisch-messungenbasiert im Falle von CP und simulationsbasiert bei umlPSI. Zum anderen wurden diese Verfahren ausgewählt wegen ihrer Werkzeugunterstützung und Integration in einen SoftwareEntwicklungsprozess. Von 31 Versuchsteilnehmern werden vorgegebene Entwurfsalternativen für die Architektur eines Beispielsystems (eines Webservers) mit den drei verschiedenen Verfahren bewertet und diese Bewertung mit der gemessenen Performanz der Implementierungen der Entwurfsalternativen verglichen. Eine Kontrollgruppe löste die Aufgabenstellung intuitiv (d.h. ohne Anwendung eines Verfahrens). In dieser Studie wurden die Metriken zur Auswertung der Daten gemäß der Goal, Question, Metric-Methode [BCR94] (GQM) nach Basili und Rombach definiert. Das Ziel der hier vorgestellten Fallstudie bestand in der empirischen Bewertung der Anwendbarkeit von PerformanzVorhersageverfahren für Software-Architekturen aus der Sicht des Entwicklers. Dabei wird unter der Anwendbarkeit zum einen eine nachvollziehbare Durchführbarkeit des Verfahrens und zum anderen die Ermittlung hilfreicher Ergebnisse verstanden. Die Beantwortung der nachfolgend formulierten Fragestellungen trägt zur Erreichung des aufgestellten Ziels bei. Weitere Fragestellungen wurden in [Koz04] formuliert und beantwortet, deren Betrachtung liegt jedoch außerhalb des Fokus dieses Artikels. 1. Wie gut lässt sich mit den Verfahren die Realisierbarkeit quantitativer PerformanzAnforderungen feststellen? 2. In wie weit unterstützen die Verfahren die Auswahl der richtigen Entwurfsalternative? Die zur Bestimmung der Antworten auf die Fragen notwendigen Metriken werden in Abschnitt 4 zusammen mit den jeweiligen Daten vorgestellt. Der Beitrag dieses Artikels besteht primär in dem Vergleich und der Bewertung der o.a. Performanz-Vorhersageverfahren für Software-Architekturen hinsichtlich der korrekten Unterstützung von Entwurfsentscheidungen und Bewertung von Performanz-Anforderungen. Sekundär besteht der Beitrag in der Beschreibung einer Methode zur Evaluation von Performanz-Vorhersageverfahren, die auch auf andere Vorhersageverfahren für Performanz anwendbar ist. Dieser Artikel ist wie folgt aufgebaut. In Abschnitt 2 werden die Performanz-Vorhersageverfahren vorgestellt. Abschnitt 3 beschreibt die Durchführung der empirischen Untersuchung, das Beispielsystem und die zu bewertenden Entwurfsalternativen. In Abschnitt 4 werden die Ergebnisse dargestellt. Abschnitt 5 diskutiert die Grenzen der Gültigkeit der Ergebnisse. In Abschnitt 6 wird der Artikel zusammengefasst und Folgefragestellungen werden diskutiert. 2 Vorstellung der untersuchten Verfahren Die Performanz-Vorhersageverfahren unterscheiden sich im Wesentlichen in den Eingabedaten (die Architektursichten, bzw. die für die Analyse benötigten Performanz-Attribute), den Performanz-Modellen und den Analysemethoden. SPE-Verfahren Beim SPE-Prozess [Smi02] werden für jedes Performanz-kritische Szenario in einer Architektur Softwareund Systemausführungsmodelle erstellt. Das Softwareausführungsmodell in Form eines Ausführungsgraphen enthält Informationen über den Software-Ressourcenbedarf jeder einzelnen Aktion eines Szenarios, deren Ausführungswahrscheinlichkeiten und die Ausführungshäufigkeiten von Schleifen. Damit können ’best-/worst-case’ Antwortzeiten für ein Szenario berechnet werden. Das Systemausführungsmodell in Form eines Warteschlangenmodells enthält Informationen über Art und Anzahl von Hardware-Ressourcen des Systems und deren Verbindungen untereinander. Die Eingabeparameter für dieses Warteschlangenmodell werden aus dem Softwareausführungsmodell bezogen, zusätzlich muss die Ankunftsrate der Anfragen bzw. die Anzahl der Benutzer im System angegeben werden. Durch Analyse der Warteschlangenmodelle können die Auslastungen der Ressourcen und mittlere Antwortzeiten des Systems berechnet werden. Die Modelle werden aus einer erweiterten Form von UML-Sequenzdiagrammen und Verteilungsdiagrammen erstellt. Dabei wird der Entwickler durch das Werkzeug SPE-ED unterstützt, das auch die automatische Auswertung der Modelle ermöglicht sowie eine graphische Visualisierung der Ergebnisse bietet. umlPSI-Verfahren Das umlPSI-Verfahren [BM03, BMDI04] beruht auf ausführbaren Simulationen. Das Verfahren lässt sich aufgrund der Nutzung von UML-Diagrammen und der Verfügbarkeit eines Werkzeugs zur automatischen Erstellung der Simulationen leicht in den Software-Entwicklungsprozess integrieren. Das Verfahren geht aus von Anwendungsfall-, Verteilungsund Aktivitätsdiagrammen der UML, mit denen die zu untersuchende Architektur modelliert wird. Alle Diagramme werden mit Hilfe des UML Profile for Schedulability, Performance, and Time [OMG03] mit Performanz-Angaben versehen. Verschiedene Simulationsparameter wie die maximale Dauer oder die gewünschte Genauigkeit der Ergebnisse können eingestellt werden. Die Ausführung der Simulation mit dem Werkzeug liefert für alle Anwendungsfälle die mittleren Antwortzeiten und für alle Ressourcen Durchsätze und mittlere prozentuale Auslastungen. Die Ergebnisse werden in das UML-Modellierungswerkzeug übertragen und sind dort einsehbar. Capacity-Planning-Verfahren Das Capacity-Planning-Verfahren [MAD04] wird zur Modellierung eines bestehenden Systems verwendet. Das Ziel ist die Vorhersage künftiger Performanz-Eigenschaften bei einem sich ändernden Nutzungsprofil. Ausgangspunkt für die Performanz-Modellierung ist eine meist textuelle Beschreibung der Systemarchitektur zusammen mit einem repräsentativen Nutzungsszenario, das die Typen und Anzahl der Eingaben an das System charakterisiert. Durch ein Monitoring des System werden möglichst viele Performanz-Daten des Systems erfasst. Diese Daten dienen als Eingabeparameter für ein Warteschlangenmodell, das auf Basis der Systembeschreibung erstellt wird. Mit diesem Warteschlangenmodell und Vorhersagen für das künftig zu erwartende Nutzungsprofil des Systems kann die zukünftige System-Performanz analysiert werden. Es kann festgestellt werden, bei welcher Systemlast bestimmte Ressourcen überlastet werden. Für verschiedene Entwurfsalternativen und Systemarchitekturen können die erwarteten Antwortzeiten und Ressourcenauslastungen vorhergesagt werden. 3 Methodik und Durchführung Bei der Wahl einer Forschungsmethode wurde zunächst die Durchführung eines kontrollierten Experiments [Pre01] favorisiert. Die Kontrolle in einem solchen Experiment ergibt sich daraus, dass bis auf die eingesetzten Verfahren alle anderen Faktoren, die das Ergebnis beeinflussen könnten, konstant gehalten werden. Aufgrund der geringen Teilnehmerzahl konnte in dieser Untersuchung jedoch nicht die Qualifikation und Leistungsfähigkeit der Versuchsteilnehmer durch statistische Methoden kontrolliert werden. Es war nicht möglich, einen Hypothesentest durchzuführen. Das folgende Experiment hat den Charakter einer vergleichenden Fallstudie. Diese Fallstudie wurde parallel von 8 Teilnehmern pro Gruppe durchgeführt, um den Einfluß der individuellen Fähigkeiten auf die Ergebnisse zu kontrollieren. Beteiligt an der Studie waren insgesamt 31 Informatik-Studenten mit abgeschlossenem Vordiplom, die alle erfolgreich ein Software-Praktikum absolviert hatten, jedoch noch unerfahren mit Performanz-Analysen waren. Die Durchführung der Fallstudie erfolgte in drei Schritten. 24 Teilnehmer wurden zunächst in den drei genannten Verfahren geschult, während 7 weitere eine ungeschulte Kontrollgruppe bildeten. Von allen Teilnehmern wurden im zweiten Schritt jeweils fünf Entwurfsvorschläge für einen experimentellen Webserver untersucht. Dabei lag ihnen kein Programmcode vor, mit dem Messungen hätten angestellt werden können. Jeder Teilnehmer gab entweder auf Basis der Verfahren oder (im Fall der Kontrollgruppe) intuitiv eine Empfehlung ab, von welcher Variante des Webservers die beste Performanz zu erwarten sei. Im dritten Schritt wurde der Webserver in den fünf vorgeschlagenen Versionen implementiert und die Performanz gemessen. Die Vorhersagen der Studenten konnten nun mit den tatsächlichen Werten verglichen werden. Schulung und Vortest Die drei Performanz-Vorhersageverfahren wurden den Teilnehmern jeweils während zweistündiger Trainingssitzungen vorgestellt. Zur aktiven Auseinandersetzung mit den Verfahren und Einarbeitung in die entsprechenden Werkzeuge wurde zusätzlich am Ende jeder Sitzung ein Übungsblatt ausgegeben, das die Studenten innerhalb einer Woche bearbeiteten. Die Schulung konnte so auch als Vortest für die spätere Untersuchung des Webservers genutzt werden, um zu prüfen, dass die Aufgabenstellung verständlich und lösbar ist. Durch die Auswertung der Übungslösungen konnten Rückschlüsse auf die Leistungsfähigkeit der Studenten gezogen werden. Die Teilnehmer wurden daraufhin für das Experiment in drei Gruppen vergleichbarer Leistung eingeteilt, so dass jeweils acht Personen einzeln mit genau einem Verfahren die Architektur des Webservers untersuchten. Experiment Das Experiment fand in einem Rechnerraum unter kontrollierten Bedingungen statt, so dass sich die Teilnehmer nicht untereinander beeinflussen konnten. Jedem Studenten standen zwei Stunden Zeit zur Verfügung. Untersuchungsobjekt war ein experimenteller Webserver, der in unserer Gruppe zu Testzwecken in der Programmiersprache C# entwickelt wurde. Der Server bietet die üblichen Funktionen zur Beantwortung von Anfragen nach dem HTTP-Protokoll. Er ist multithreaded und kann über die Anbindung einer Datenbank auch dynamisch HTML-Dateien erzeugen. Die genaue Beschreibung des Webservers findet sich in [Koz04]. Folgende Entwurfsalternativen zur Optimierung der Performanz wurden für das Experiment zur Evaluation vorgesschlagen: 1a) Statischer Cache: für die Auslieferung statischer Inhalte wird ein Cache eingebaut. Auf diese Weise können teure Festplatten-Zugriffe eingespart und die Dateien aus dem Hauptspeicher bezogen werden. Die zu erwartende Wahrscheinlichkeit eines Cache-Hits wurde auf 70% festgelegt. 1b) Dynamischer Cache: für die Auslieferung dynamischer Inhalte, die sich nicht bei jeder Anfrage ändern (z.B. aktuelle Lagerbestände, tägliche Wetterdaten), wird ein Cache eingebaut. Dabei können die Zugriffe auf einen externen Datenbankserver eingespart werden, jedoch liegt die zu erwartende Wahrscheinlichkeit eines Cache-Hits hier nur bei 20%. 2) Single-threaded Server: Der Server wird in einer single-threaded Variante implementiert. Das bedeutet, dass nicht für jede Anfrage ein neuer Programmthread abgespalten wird, sondern die Anfragen werden sequentiell hintereinander bearbeitet werden. Bei einer niedrigen Auslastung des Servers könnte es so möglich sein, Zeit für den Start und Kontextwechsel von Threads einzusparen. 3) Komprimierung: Inhalte werden vor dem Versand auf dem Server komprimiert. Dies muss aufgrund der möglicherweise dynamischen Inhalte bei jeder Anfrage erfolgen und verbraucht eine gewisse Rechenzeit für den Kompressionsalgorithmus. Jedoch könnte bei langsamen Internetverbindungen durch die reduzierte Datenmenge möglicherweise viel Zeit für das Versenden eingespart werden. 4) Clustering: Durch die Verteilung des Webservers auf zwei unabhängige Server kann die maximale Anzahl der beantwortbaren Anfragen erhöht werden. Jedoch ist zu prüfen, ob bei einer niedrigen Beanspruchung des Servers ein Performanz-Gewinn nicht durch den erhöhten Verwaltungsaufwand kompensiert wird. Für diese Alternativen sollten die Teilnehmer folgendes Nutzungsszenario des Webservers untersuchen: Die Ankunftsrate von Anfragen betrug eine Anfrage pro Sekunde. Es wurden zu 40% statische und zu 60% dynamische Inhalte abgefragt und die mittlere Größe der abgefragten Dateien betrug 5 KByte. Clients griffen über eine einfache ISDN-Verbindung (64 KBit/s) auf den Server zu. Der Server wiederum war über eine LAN-Verbindung (10 MBit/s) mit einem Datenbankserver verbunden, aus dem Inhalte für die dynamischen Anfragen bezogen werden konnten. Dabei wurde die mittlere Zeit für eine Datenbankabfrage mit 0,5 Sekunden vorgegeben. Den Teilnehmern wurden ergänzend zu diesen Angaben UML-Diagramme und Warteschlangenmodelle der Architektur vorgelegt. Die acht Studenten, die das Capacity Planning anwandten, erhielten zusätzlich eine künstlich erzeugte Logdatei, in der die Verbrauchszeiten von CPU, Festplatte und LAN für 1000 Anfragen an den Server vermerkt waren. Diese Werte wurden mittels Messungen am Prototypen des Webservers vor dem Experiment bestimmt. Die Vorgabe war notwendig, da die Teilnehmer bei diesem Verfahren diese Daten für ihre Berechnungen benötigten. Mittels der Verfahren berechnete jeder Teilnehmer für alle Varianten jeweils die Durchlaufzeiten für statische bzw. dynamische Anfragen. Alle im Experiment untersuchten Entwurfsalternativen wurden implementiert und vermessen. Details über den technischen Aufbau des Meßverfahrens und der Ablaufumgebung sind in [Koz04] dokumentiert.